【企業セキュリティ】Google CloudのIAM構造を理解して、効率的なアクセス制御を実施する

IAMの概要

ポリシー

Google Cloudを利用する際に必ず必要になってくるのが、権限管理です。
IAM（Identity and Access Management）という概念を利用し、ユーザーに権限を割り当てることでリソースの操作を可能にします。

今回はポリシー（上記画像を参照）を割り当てていくレベルについて解説していこうと思います。
ポリシーの割り当てレベルを知ることで、より包括的にそして煩雑な権限の運用から解放されることと思います。

Google Groupの利用

まず、権限管理で欠かせない機能としては、Google Groupが挙げれます。
複数のユーザーを1つのグループにまとめ、そのグループに対して一括で権限を付与することができます。

これにより、個々のユーザーに対する権限管理の手間が大幅に削減され、組織の変更に柔軟に対応でき、新メンバーの追加や退職者の削除も容易に行えます。

Google Groupは全ての階層構造レベル（組織、フォルダ、プロジェクト、リソース）で活用可能で、大規模な組織での権限管理に特に有効です。

IAM ポリシーの継承

上位レベル（組織やフォルダ）で設定されたポリシーは、特に明示的に拒否（拒否ポリシーなど）されない限り、下位のリソースに自動的に継承されます。

例えば、フォルダレベルで設定された閲覧権限は、そのフォルダ内の全プロジェクトに適用されます。
ただし、下位レベルで追加の権限を付与することも可能で、これにより柔軟な権限設計が実現します。

継承を理解し適切に活用することで、管理の簡素化とセキュリティの向上の両立が図れます。

ポリシーの適応

組織レベル

Google Cloudには組織というルート概念が存在します。
いわばその企業をGoogleクラウド内で識別するようなものであり、1社で組織を数十個持つということは基本的にはないと思います。（部署単位で組織を作成する場合には増える可能性はある）

よって、この組織というリソースにポリシーを割り当てることで、その企業のリソース全てにおいてそのポリシー（権限）が適用されます。（＝階層構造）

このことから、組織レベルで付与するポリシーについては、かなり狭めた権限で付与することをお勧めします。
例えば、組織レベルでオーナーロールを持つユーザーを割り当ててしまった場合、そのGoogle Cloud組織内におけるスーパーユーザーレベルの権限を持つことになります。

さらに最小権限の原則という権限を絞った運用が推奨されているため、ベストプラクティスにも反するような運用となってしまいます。

ただし、その企業においてすべてのプロジェクトやユーザーの挙動を把握しなければいけない理由がある部門（情シスなど） のユーザに対しては、組織レベルでモニタリング閲覧者やログ閲覧者ロールなどを与えることが検討できます。

大きな単位で権限を付与できるメリットと、そのデメリットを考えて、組織レベルでの権限付与を考えてください。

フォルダレベル

組織の直下に存在する概念としてフォルダがあります。
部門ごとにGoogle Cloudプロジェクトを分ける際に使用する時になどに利用できます。

組織の直下に存在すると説明しましたが、もし部門ごとにプロジェクトを分ける運用の場合、その部門のルートがフォルダに当たります。
基本的には組織レベルで権限を割り当てるより、フォルダレベルで詳細な権限を適応させるのが一般的かもしれません。

プロジェクトレベル

環境ごとにプロジェクトの運用を分けたいときに使用するのがプロジェクトレベルでの権限分掌です。
例えば、アプリAの開発環境、検証環境、本番環境などといった利用です。

よって、プロジェクトの数は比較的多くなりやすく、デフォルトで作成できるプロジェクト数も限られているので、あらかじめプロジェクトの数を多く利用できるようにGoogle Cloudにリクエストをすることも検討してください。

冒頭の情報と重なりますが、プロジェクトレベルでの権限分掌のメリットは、各環境に対して適切なアクセス制御を設定できる点です。

例にすると、開発者には開発環境のみにアクセス権を与え、運用チームには本番環境へのアクセス権を付与するといった具合です。（Google グループを利用すればまとめて同じ権限を付与できます）

事前に必要なプロジェクト数を見積もり、十分な余裕を持ってクォータの増加申請を行うことにより、スムーズな環境構築と効率的な運用が可能となります。

リソースレベル

Google Cloudの最も細かい権限管理単位として、リソースレベルでのアクセス制御があります。
これは特定のリソース（Cloud Storage バケット、BigQueryデータセットなど）に対して直接ポリシーを適用する方法です。

リソースレベルでの権限管理は、より精緻な制御が可能になるため、セキュリティ要件の厳しい環境や、複雑な権限設定が必要な場合に特に有用です。

リソースレベルでのアクセス制御のメリットは、必要最小限の権限を付与できることです。例えば、特定のCloud Storageバケットに対して読み取り権限のみを付与したり、特定のBigQueryデータセットに対して書き込み権限を与えたりすることが可能です。

ただし、リソースレベルでの権限管理のデメリットとして、詳細さゆえに管理が複雑になる可能性があります。

多数のリソースに対して個別に権限を設定する必要があるため、権限管理のオーバーヘッドが大きくなる可能性があります。

リソースレベルでの権限管理を効果的に活用するためには、以下のような点に注意が必要です。

• 権限の継承を理解する: 上位レベル（組織、フォルダ、プロジェクト）で設定された権限は、特に明示的に拒否されない限り、リソースレベルにも継承される。
• 最小権限の原則を適用する: 必要最小限の権限のみを付与し、過剰な権限付与を避ける。（これは全てに言えること）
• 定期的な権限の見直し: リソースレベルの権限設定は個々で都度確認しなければならないため、定期的な見直しを怠らず不要な権限を削除する。
• IAMポリシーの一貫性を保つ: 組織全体で一貫したIAMポリシーを維持する前提として、個々のリソースでのIAM設定により、セキュリティの穴を作らないようにする。

リソースレベルでの権限管理は、より細かい制御が可能になるメリットがある一方で、管理の複雑さというデメリットもあり、すべてのGoogle Cloudサービスがリソースレベルのアクセス制御をサポートしているわけではありません。

サービスによっては、プロジェクトレベルでの権限設定しかできない場合もありますのでご注意ください。

まとめ

以上のように、Google CloudでIAMを管理する場合には「組織、フォルダ、プロジェクト、リソース」の各レベルでの権限管理が必要となります。途中でも触れましたが、これらは最小権限の原則に基づき適切なレベルで権限を付与することが重要です。

またGoogle Groupの活用や権限の継承を理解することで、効率的かつセキュアな権限管理が可能となります。各レベルのメリットとデメリットを考慮し、組織のニーズに合わせた最適な権限設計を行うことが推奨されます。

IAM設計やGoogle Cloud組織運用についての疑問があれば、ぜひクラスメソッドにご相談ください。